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. Abstract. We present a solution to the problem of privacy invasion in 

a multiparty digital rights management scheme. (Roaming) users buy 

^^ content licenses from a content provider and execute it at any nearby 

content distributor. Our approach, which does not need any trusted third 

^^ party — in contrast to most related work on privacy-preserving DRM — is 

C*) based on a re-encryption scheme that runs on any mobile Android device. 

Only a minor security-critical part needs to be performed on the device's 

f^j smartcard which could, for instance, be a SIM card. 

u 

c/3 1 Introduction 

Mobile users are used to access digital content provided in the cloud from any- 
t-H where in the world today. Music streaming services like Spotify enjoy great pop- 

ularity among users. The lack of bulky storage on mobile devices (mobile phones, 
tablets, etc.) is compensated for by such services by streaming the content (mu- 
sic and films) to the users's devices. Content is downloaded on demand and can 
00 be used only during playback (or is cached temporarily). Thus, paying users are 

I* able to access huge amounts of content. There also exist certain price models 

f— ^ that allow the playback of content only for a certain number of times, until a 

C*") specific day (e.g., movie rentals), etc. 

In a "simple" digital rights management (DRM) architecture, there would 

^. be only two parties involved: a user who wants to get access to content and the 

T *~j content provider that cither grants or denies access depending on the payment 

r% status. However, in more advanced and realistic scenarios, we would have a con- 

5— i . . ... 

C^ tent provider that sells licenses — granting certain rights for content playback — to 

users and there would be a number of content distributors that provide the (pro- 
tected) content. This allows for a better scaling of the service as users can access 
content from those content distributors that are closest or that provide best ser- 
vice at the moment. This bears advantages for roaming users as they can choose 
local distributors to access the content from. For the content distributor to be 
able to decide whether the user is allowed to playback the content, the user 
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first needs to present the purchased license. Such scenarios, consisting of content 
providers and distributors, are called multiparty DRM systems in the literature. 

A drawback of most of today's DRM systems is that content providers/dis- 
tributors are able to build content usage profiles of their users as they learn 
which user plays back certain content at a certain time, etc. This is the point 
where we contribute with this paper. We suggest a privacy-preserving multiparty 
DRM system. In such a system, users are able to anonymously buy content and 
anonymously playback the content. Moreover, neither the content providers nor 
the content distributors are able to link content playbacks to each other and thus 
are not able to build usage profiles under a pseudonym — as the past has shown 
that even profiles under a pseudonym, assumed to be unrelatable to users, can 
be related to users given external information and thus, inverting user privacy 
again [lj. One major advantage of our approach compared to related work on 
privacy-preserving DRM is that we do not need a trusted third party (TTP) 
which needs to check licenses before allowing content executions. 

The paper is structured as follows. Related work is covered in Sect. [5] and 
the preliminaries in Sect. [3] In Sect. [4] we present the system model of our multi- 
party DRM scenario and present the corresponding requirements. Our proposed 
privacy-preserving multiparty DRM system is presented in Sect. [5j We discuss 
and evaluate our proposed concept in Sect. [6] before we conclude in Sect. [7] 

2 Related Work 

In this section we first give a short overview of related work on the building 
blocks of our proposed concept. Then we investigate state-of-the-art research of 
privacy-preserving DRM. 



2.1 Proxy Re-Encryption 

Proxy re- encryption allows a proxy to transform an encrypted message under 
^4's public key into another encrypted message under B's public key — without 
seeing the message in plain text. For this, a re-encryption key rkA^B is used. The 
proxy does not need the private key of A to decrypt the message and encrypt it 
again under B's public key. Ateniese et al. [2J introduce several unidirectional 
proxy re-encryption schemes — one of them is covered in Sect. [31 

2.2 Anonymous Payments 

The anonymous payment scheme used in this paper has been introduced by 
Tewari et al. J3J. Analyses of this method have proven it to be more suited 
for our application in comparison to the frequently cited scheme by Chaum (4) 
in [5J. This is because of the chosen system being more flexible. Another reason 
behind choosing this protocol is that the Point of Sales (POS) devices used 
provide another layer of anonymity for the user since these device serve as a proxy 
between the user and the payee. Contrasting the basic version 13], however, we 



provide extensions such as the payment of change in case the user does not have 
the right amount of money in his/her wallet. The anonymous payment scheme 
does not allow any party to get to know which content has been purchased if 
the user makes legitimate payments only. If the user tries to defraud some party, 
however, his/her identity can be unveiled so that he/she can be held accountable. 



2.3 Privacy-preserving DRM 

In Rjj, Mishra et AL. propose a scenario where a content owner provides its (en- 
crypted) content to users via a number of different (local) content distributors — 
which is similar to our scenario. Employing this scheme, users can buy licenses 
for content from a license server, acting as trusted third party. Once a license is 
bought, the user gets in possession of the decryption key which allows him/her 
to access the content as often as desired. Differentiated license models are not 
intended in their approach — however, if license enforcement additionally took 
place on the client-side, differentiated license models could be implemented. As 
content download and license buying are done anonymously, none of the parties 
can build profiles of users' interest in content. 

Win et AL. [7] present a privacy-preserving DRM scheme for two- and mul- 
tiparty scenarios without needing a TTP. A user anonymously requests a token 
set from the content owner that allows anonymous purchase of content licenses 
from content providers. A drawback is that content providers are able to build 
usage profiles of content executions under a pseudonym. 

Petrlic et AL. M present a DRM scenario that allows users to anonymously 
buy software from any software provider and execute it at any computing center 
within the cloud. The users' permission to execute the software is checked before 
every single execution. Their solution is resistant against profile building. The 
authors suggest employing a software re-encryption scheme that is based on 
secret sharing and homomorphic encryption to achieve unlinkability of software 
executions towards the computing center. Their software re-encryption scheme 
is rather complex and implies a huge communication overhead. The approach is 
extended in [9] by employing an adapted version of proxy re-encryption [2] . The 
scheme makes explicit use of a service provider as a TTP. 

The approach towards privacy-preserving DRM by Joshi et al. [To] also 
requires a TTP for license checking before content execution. It makes use of a 
number of cryptographic primitives such as proxy re-encryption, ring signatures 
and an anonymous recipient scheme to provide unlinkability of content execu- 
tions. The scheme's advantage is the reduced computation and communication 
overhead compared to the approaches above. 



3 Preliminaries 

Definition 1. Unidirectional Proxy Re-Encryption pa 



A unidirectional proxy re- encryption scheme is a tuple of polynomial time 
algorithms (KG, RG, E\, E%, R, D). The randomly chosen g G Gi and Z = 
e(g,g) € G2 constitute the global system parameters. 

— Key Generation (KG): KG generates a public key pk a = (Z ai ,g a2 ) and a 
private key sk a = (01, 0,2) for A, where a\, ai G Z g are chosen randomly. 

— Re-Encryption Key Generation (RG): A delegates to B by publishing rk^^g - 
gaxb 2 g q 1 _ p or ifoai purpose, A needs B's public value g b2 . 

— First-Level Encryption (E\): m G G2 is encrypted under Z ai G pk a by 
outputting c — (Z aik ,mZ k ), where k G Z* is chosen randomly. Note that 
^a ± k _ e (g a i ^g k y The message can be decrypted by the holder of a\ G sk a . 

— Second-Level Encryption (E2): m G G2 is encrypted under pk a by outputting 
c = (g k ,mZ aik ). Second-level ciphertexts can be transformed to first-level 
ciphertexts by re- encrypting them. 

— Re-Encryption (R): A second-level ciphertext for A can be changed into a 
first-level ciphertext for B with rkA^B — g aib ' 2 . From c — (g k ,mZ aik ), 
compute e{g k ,g aib2 ) = Z b ' 2aik and output c = (Z b2aik ,mZ aik ). 

— Decryption (D): 

• A (re- encrypted) first-level ciphertext c — (a, 0) (for B) is decrypted with 
private key 62 € sks by computing m — 1/b2 . 

• A first-level ciphertext c = [a.,0) (for A) — computed using E\ — is de- 
crypted with private key a\ G s&u by computing m — {j . 



4 System Model 

The system model is shown in Fig. [T] on a high abstraction level. We are dealing 
with a multiparty DRM scenario that involves content providers (CPs), content 
distributors (CDs), and users. The focus, as shown in the figure, is on mobile 
users with different content access devices (CADs) accessing content. However, 
the scenario is not limited to mobile devices. As devices have different hardware 
trust anchors — e.g., smartphones typically are equipped with SIM cards, tablet 
computers have trusted platform modules (TPMs), etc. — we subsume those trust 
anchors under the term smartcards in the followingF] 

The CP takes the role of, e.g., a film studio or music label that produces 
content. Users interact with the CP by buying a license that allows playback 
of the content — under certain terms that are mediated. The user's smartcard is 
used to check whether the user is still allowed to access the content. Then, a 
nearby CD is contacted and the CD streams the content to the user. The CD 
can have contracts with different CPs, which allows the user to access content 
by different CPs from a single source — as it is the case with state-of-the-art 
streaming servers as well. The CD might get paid for providing its services by 
the CPs (or even the users). We do not cover this aspect in the paper at hand. 



1 Note that SIM cards are smartcards and TPMs can be seen as a special form of 
smartcards as well. 
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Fig. 1: System model of a multiparty DRM scenario. 



We assume that the CPs and CDs are honest-but-curious, i.e., they follow 
the protocol, as specified in Sect.[5j but they try to find out as much as possible 
to track users. Users can be assumed as active adversaries, meaning that they 
try to break the protocol to be able to execute content without having a license. 

Our protocol is not based on any TTP that would be needed to check licenses. 

4.1 DRM requirements 

In a multiparty DRM scenario, there are a number of stakeholders with diverse — 
sometimes even contrary — requirements. In our scenario, we can identify the 
content provider, content distributoirj and the user as main stakeholders. The 
requirements, specified per stakeholder, are as follows: 



Content provider 

— Req. I: Flexibility in choosing a license model. 

— Req. II: Protection of the content (confidentiality) . 

— Req. Ill: Enforcement of licenses. 



Req. I, in line with, for instance, 11 for Spotify's music licensing, particularly 



asks for the following license models: 

— execute at most n-times-mode\s that allow only up to n content executions. 

— pay per execute-models that allow only one execution per payment. This is 
a special case of execute at most n-times-license models. 

— execute until-models that allow an unlimited number of executions of a con- 
tent until a certain time. 



2 As stated above, we do not investigate the CD as a stakeholder in detail — we can 
assume that it gets paid by the CP or the user for its services. 



It is important to note that the employed license model determines the way 
in which content is or can be used, which is why there is a need for freedom in 
choosing such models on the CP's side. One aspect CPs might want to define is, 
e.g., the number of times a user will be able to access content. Hence, the chosen 
license model needs to be capable of reflecting such statements. Employing dif- 
ferent license models, applications like movie renting can be realized effortlessly. 
Further, degressive pricing can be established, meaning that users who buy a 
certain number of executions (in the execute at most n-times-license model) are 
granted a discount: For example, if a user decides to buy 10 instead of only one 
execution, he/she may be granted a 10% discount. 

Regarding Req. II, the CP — publicly providing the content in protected form — 
needs assurance that the content cannot be accessed by any party without proper 
rights. This requirement addresses third parties that have not purchased any con- 
tent license. Moreover, Req. Ill addresses users who are in possession of a license 
for the content they want to execute. The CP needs to be sure that the license 
terms will be checked before the content is allowed to be executed. This is neces- 
sary for, e.g., execute at most n-times-models in which case the n+ 1 st execution 
shall not be allowed for users who have only paid for n content executions. 



User 

— Req. IV: Profile building (under a pseudonym) must not be possible for any 
involved party. To achieve Req. IV, several requirements need to be met: 

1. Anonymous content (license) buying towards content provider, and anony- 
mous content execution towards content distributor. 

2. Unlinkability of content (license) purchases towards the content provider. 

3. Unlinkability of content executions towards the content distributor. 

To precisely define anonymity and unlinkability of items of interest (IOIs) 



we have the following definitions 12 



Anonymity and unlinkability of items of interest (IOIs) are defined as 12 



Definition 2 (Anonymity). Anonymity of a subject from an attacker's per- 
spective means that the attacker cannot sufficiently identify the subject within a 
set of subjects, the anonymity set. 

Definition 3 (Unlinkability delta). The unlinkability delta of two or more 
IOIs from an attacker's perspective specifies the difference between the unlinka- 
bility of these IOIs taking into account the attacker's observations and the un- 
linkability of those IOIs given the attacker's a-priori knowledge only. 

Definition 4 (Unlinkability of IOIs). Unlinkability of IOIs is given iff the 
unlinkability delta of two or more IOIs from an attacker's perspective is negli- 
gible. 



Thus, (1) is achieved if neither the CP nor the CD can link a purchase/exe- 
cution to a certain user, i.e., the user is not identifiable by those parties. Put (2) 
in other words, after protocol execution, the CP's probability in linking content 
(license) purchases (IOIs) to each other has not changed compared to the prob- 
ability in linking them to each other before the protocol execution. The same 
is true for (3), i.e., the CD's probability in linking content executions (IOIs) to 
each other does not change during protocol execution. 

Any party that was able to link IOIs to each other with non-negligible prob- 
ability would be able to build a usage profile under a pseudonym. Such profile 
building under a pseudonym is an entity's ability to track a user's actions (un- 
der his/her pseudonym). If the CP/CD had such a profile, meaning it knew the 
accessed content, it might have a chance to de-anonymize the user, i.e., relate 
the pseudonym to an identity, given some external information — as shown, for 
example, by the de-anonymization of the "anonymized" Netflix database 111. 
Thus, user privacy can only be achieved if profile building under a pseudonym 
can be prevented (unlinkability is a sufficient condition for anonymity |12|). 



5 Privacy-preserving multiparty DRM system 

In a multiparty DRM system, there are multiple content providers (CPs) that 
produce some sort of content, e.g., software, movies or music. The CPs only 
offer licenses for the given content. The content itself is delivered to the user 
by content distributors (CDs), if and only if the user owns a valid license, that 
he/she has purchased from a CP before. 

A multiparty DRM system, such as the one depicted in Fig. [T] requires some 
questions to be answered: Without a TTP, it needs to be considered how license 
checking is performed and which entity is in charge of storing the user's pur- 
chased content. Moreover, as stated above, it is necessary to prevent the CP and 
the CD from creating user profiles (under a pseudonym). 

To resolve these issues, we devised a protocol that involves a smartcard. That 
is, instead of collaborating with a TTP, every user will employ a smartcard that 
has been provided to him/her. Such a smartcard contains a digital certificate that 
is used for (anonymous) authentication with CPs. Further, the user's smartcard 
assumes the role of his/her proxy. Thus, the user's smartcard executes an anony- 
mous payment scheme (e.g., [3]) to pay the CP the corresponding amount for 
the requested license without disclosing any information about the user. 



5.1 Protocol Description 

The protocol is divided into several sub-protocols which work as follows. 



System Initialization Let Gi and G2 be cyclic groups with the same prime 
order q, the security parameter n = ||q||, <g> = Gi, and Z = e{g,g) £ G2. 



Every smartcard is programmed and shipped by trustworthy smartcard 
providers. These providers install a private key sk sc and the corresponding dig- 
ital certificate cert sc on every smartcard before shipping them. The private key 
and certificate are shared by all smartcards since they are used for anonymous 
authentication towards the CP during the process of purchasing content. Au- 
thentication of smartcards is required so that only legitimate smartcards can be 
used to purchase content, however, CPs must not be able to recognize smart- 
cards. Moreover, the current time of production of the smartcard is set as the 
smartcard's timestamp ts. 

Content offered by the CP is encrypted using a symmetric encryption algo- 
rithm such as AES 
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and a separate content key cki for each content i. 
The user sets up an anonymous payment scheme with his/her bank to get 
supplied with payment tokens pt. 



Content Purchase The content purchase protocol is shown in Fig. [2j We 
assume that the connection between the user and the CP is anonymized (e.g., 
by using an anonymization network such as Tor |14|). 
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Fig. 2: Content purchase protocol. 



3 Note that these providers are not system-specific; any smartcard provider which is 
considered "trustworthy" today can be used to ship these smartcards. 



The user initiates the content purchase via his/her content access device 
(CAD), i.e., mobile phone, by authenticating towards the smartcard with his/her 
PIN (1) and initiating the TLS handshake with the CP (2). For reasons of read- 
ability, we do not show the entire TLS handshake [15] — using the RSA key 
exchange method — in the diagram, but rather focus on the important parts con- 
cerning the combination of the TLS handshake and the client authentication. 
In step (2), the smartcard executes the KG algorithm as in Sect. [3] to gener- 
ate a temporary key pahr] (pk-tmp sc = (Z ai , g a2 ), sk-tmp sc — (ai,a 2 )), where 
<Zi , CL2 € Z 9 are chosen randomly. During the TLS handshake in step (4) , the CP 
challenges the CAD's smartcard with a noncejj r and asks for the smartcard's 
certificate. The CAD forwards r to the smartcard (5) which signs r and pk-tmp sc 
with the smartcard's private key sk sc (6). The signature and the smartcard's 
certificate cert sc , as well as pk-tmp sc are forwarded to the CAD (7) and the CAD 
forwards them, together with the content-idi of the content i to be bought, as 
well as the payment token pt to pay for the license (8). From this moment on, 
the communication between CAD and CP is authenticated and encrypted via 
TLS. The CP verifies the response by checking the signature (9). This way, the 
CAD's smartcard has anonymously authenticated towards the CP, meaning the 
CP knows that pk-tmp sc is from an authentic smartcard and the corresponding 
sk-tmp sc does not leave the smartcard. The CP creates the license for content i. 
This license includes a license identifier id, a timestamp ts, the content-idi, the 
license terms, and the CP's certificate cert cp (10). Note that the license terms 
depend on the license model, i.e., for execute at most n-iimes-models, the terms 
include the maximum number of allowed executions n. For other license models, 
the terms will differ accordingly. The license is encrypted under the smartcard's 
pk-tmp sc . Moreover, the content key cki for content i is encrypted under pk- 
tmp sc as well (11). The license, the signature of the license, the content-idi 
and the encrypted content key (cki) p k-tmp BC are forwarded to the CAD (12). 
The CAD stores (cki) p k—tmp ac (13) and forwards the license and the signature 
to the smartcard (14). The smartcard verifies the license's signature and decrypts 
the license with sk-tmp sc . Then it checks whether the id was not used before 
and whether ts is newer than the current ts on the smartcard — both to prevent 
replay attacks. The smartcard's ts is then set to the newer ts of the license|j 
Finally, the license is stored under the content-idi on the smartcard. (15) 



Content Execution The content execution protocol is shown in Fig. [3J To 
playback the purchased content, the user first selects a CD of his/her choice 
(this choice could be automated as well, e.g., dependent of the region the user 
currently is in). We assume that the connection between the user and the CD is 
anonymized (e.g., by using an anonymization network such as Tor |14| ). 

4 A new temporary key pair is used for each content purchase. 

5 number used only once 

6 Note that the smartcard does not have an internal clock and thus cannot keep track 
of (authenticated) time. The time can only be set via new and verified licenses. 
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Fig. 3: Content execution protocol. 



The CAD establishes a TLS connection [15] with the CD — the CD authen- 
ticates towards the CAD with its certificate. The CAD afterwards requests a 
new certificate from the CD (1). The CD creates a new key-pair using KG as 
in Sect.pl (pk-j c d = [Z ai ,g a2 ),sk-j c d — (01,02)), where 01,03 € 7L q are chosen 
randomly and j denotes the j th request to the CD. The pk-j cc i is included in the 
newly generated certificate cert-jcd, &s well as a unique certificate id and the 
current timestamp ts. The CD self-signs the certificatcF] (2). The certificate is 
forwarded to the CAD (3). The user authenticates towards the smartcard with 
his/her PIN entered on the CAD (4) and the smartcard then forwards the list 
of available content-ids, i.e. music/film titles, to the CAD (5). The user chooses 
the content-idi to be executed and forwards it, together with cert-j c d to the 
smartcard (6). The smartcard checks whether the signature of cert-j c d is valid, 
whether the CD was certified by a known certificate authority, whether the cer- 
tificate id was not used before and whether the ts is newer than the current ts 
on the smartcard. If these tests pass, the new ts from the certificate is set on 
the smartcard (7). It is important to note, that the smartcard checks whether 
the certificate really belongs to a CD. If this was not the case, the user might 
be able to launch an attack by including a self-signed certificate that he/she has 
generated himself/herself. Hence, if the smartcard would not verify that the cer- 
tificate belonged to a CD, the user might acquire a re-encryption key from the 
smartcard that allowed him/her to decrypt the content key, granting him/her 



7 The signing certificate was issued by a valid certificate authority, though. 



unlimited access to the content. Furthermore, the smartcard checks whether the 
license terms still allow the content to be played back, i.e., whether the number 
of executions is <n, the current ts is before the end date of the license, etc. If this 
is the case, the terms are updated, that is, e.g., a counter that counts the num- 
ber of executions is incremented by one for an execute at most n-times-\iceiise 
(8). Then, the smartcard generates the re-encryption key rk p k-tmp sc ^-pk-j cd by 
using the RG algorithm as in Sect. [SJ taking as input the CD's public key 
g a2 £ pk-j c d, and its own private key a\ € sk-tmp sc (as created during the con- 



tent purchase described in Sect. 5.1 ) (9). The re-encryption key is then forwarded 
to the CAD (10). The CAD re-encrypts the encrypted content key (cki) p k-tmp sc 
by employing the R algorithm as in Sect. [3] with rk p k~tmp BC ^pk-j cd as input to 
retrieve (cki) p k-j ad — i.e., the encrypted content key under the CD's public key 
(11). The re-encrypted content key is then forwarded to the CD (12) and the 
CD decrypts the ciphertext using the D algorithm as in Sect. [3] with its private 
key ai € sk-j cc i as input to retrieve cfcj (13). The content — retrieved from the 
CP — can now be decrypted by the CD using cki and the symmetric scheme as 



employed during the system initialization phase (Sect. 5.1 ) (14). Eventually, the 



content is provided, for example, streamed, to the user's CAD (15). 

Authorization Categories Similar to "Authorization Categories" [16] , we 
came up with the following addition to our protocol: There might be content 
that should not be accessible to everybody, such as X-rated content. To be able 
to check whether a user should be allowed to access certain content, we employ 
the smartcard of the user's CAD. Before initially obtaining a smartcard, the user 
provides certain information to the smartcard provider (e.g., his/her passport or 
state ID). The smartcard provider will then secureljrlstore the required informa- 
tion on the user's smartcard. Note that the smartcard, as well as the smartcard 
provider may obtain such information without invading the user's privacy. 

If we assume that the user's smartcard now contains information like the 
user's date of birth or home country, it can easily check whether or not the 
user is allowed to access the content he/she wishes. This means that if the user 
requests access to, for instance, X-rated content, the smartcard will check the 
user's date of birth and according to this information either allow or deny access 
to the queried content (that is, if the access is denied, the smartcard will not 



carry out the content purchase as described in Sect. 5.1 ) 



Compared to the three approaches described in 16 , we do not need to employ 
complicated protocols for checking a user's authorizations, since the required 
information are stored and checked by the user's smartcard only (i.e., neither 
CP nor CD are involved in the checking for authorization). Hence, none of the 
two, CP and CD, are burdened with additional computations. Due to the fact 
that the smartcard is assumed to be a tamper-resistant device, the user cannot 
manipulate the information stored on the smartcard and therefore is unable to 
access content that he/she lacks the authorization to. Further, this supplement 



Secure storage in this context especially means integrity-protection; this can be 
achieved by a signature calculated by the smartcard provider. 



to our protocol is optional and can be employed according to certain policies 
(e.g., in some countries particular checks might be required by law, whereas 
other countries do not pose any such requirements). 



6 Evaluation and Discussion 

In this section we discuss the protocol's performance, determine whether it meets 
the posed requirements and compare our approach to related work. 

6.1 Performance Analysis 

The protocol requires the user's CAD to execute the most complex tasks, i.e., 
perform the re-encryption of the content key. Apart from the re-encryption, the 
content provider and the smartcard are involved in a challenge-response protocol 
for authentication of the smartcard which is not too expensive. Further, the 
CP has to encrypt the content key using the smartcard's public key and the 
content using the content key. The latter is a symmetric encryption that has 
to be executed only once per content (and not for every purchase/execution). 
Additionally, the content distributor has to decrypt the re-encrypted content 
key as well as the content obtained from the CP. The required generation of 
keys is not expensive. The only concern is the re-encryption key generation 
that is performed on the user's smartcard. We were able to show that current 
smartphones are easily capable of executing the required tasks by implementing 
a demo application on an Android smartphone. We have implemented the re- 
encryption using the jPBC (Java Pairing Based Cryptography) librarjrj The 
app that has been developed re-encrypts 128 Bytes of data — the length of a 
symmetric key to be encrypted — in 302 ms on a Samsung Galaxy Nexus (2 x 
1.5 GHz) running Android 4.2. Due to a lack of a proper smartcarcPj we could 
not implement the re-encryption key generation algorithm RG as in Sect. [3j 



Thus, to show the practicability of the implementation, we must refer to 17 
The authors have implemented elliptic curve scalar point multiplications and 
additions for a smartcard in C and Assembler — which are needed in our approach 
as well. As the authors conclude, the standard Javacard API (version 2.2.2) 
cannot be used as the available EC Diffic-Hcllman key exchange only provides 
the hashed version of the key derivation function. [17] However, we need the 
immediate result of the key derivation function, i.e., the result of the EC point 
multiplication. Our own implementation of the EC point multiplication on the 
smartcard's CPU did not yield practicable results — as the efficient cryptographic 
co-processors could not be utilized due to proprietary code. 



http://gas.dia.unisa. it/projects/jpbc/ 

According to the specifications, the NXP JCOP card 4.1, V2.2.1 can be used to 

implement the needed functionality. 



6.2 Evaluation of Requirements 

Req. I: Flexibility in choosing a license model: The CP is able to provide different 
kinds of rights to users for content playback — users pay the corresponding prices. 
Our system is flexible enough to allow for the most popular models like flatrate, 
execute at most n-times, execute until a certain date, etc. 

Req. II: Protection of the content: The CP distributes its content only in 
encrypted form, as described in Sect. |5.1| Thus, none of the parties not in pos- 
session of the content decryption key is able to access the content. 

Req. Ill: Enforcement of licenses: Smartcards, as trusted devices, are used 
in our protocol to enforce licenses. Thus, if the smartcard's check of a license 
fails, the proper re-encryption key is not generated and the user is not able to 
execute the content. A replay attack of the user with an "old" CD certificate will 
fail as the smartcard will not accept the ts — since it is older than the current 
one stored on the smartcard. The smartcard's property of tamper-resistance is 
required since we assumed users to be active adversaries in Sect. [4] 



Note that during the protocol execution, the re-encryption key is "leaked" 18 
to the untrusted CAEp]in step (10). As a consequence, without protection mech- 
anisms, a user who has obtained a re-encryption key from his/her smartcard that 
was valid for a certain CD would be able to re-encrypt a content key as many 
times as he/she desired for this CD. This would defeat the purpose of license 
checking, since the user could playback content in an unrestricted fashion. This 
is why we have devised a method to prevent the user from reusing re-encryption 
keys: The transience of the CD's certificates and thus, public keys (2), prevents 
replay attacks, meaning that the user cannot reuse the re-encryption key later 
on; if the user re-encrypted a content key under a temporary public key of the 
CD that was already used before, the CD would reject the request of content 
execution, because the temporary public key has already been invalidated after 
a former execution. Hence, the user relies on his/her smartcard to generate a 
valid re-encryption key which it will only do if the user's license for the corre- 
sponding content is (still) valid. Ateniese et AL. [2] propose an addition to the 
proxy re-encryption scheme used in this paper: if a trusted server broadcasting 
some random number for each time period was assumed, the proxy re-encryption 
could be adapted so that only temporary re-encryptions are possible. Thus, the 
"leakage" problem could be minimized. However, in our scenario we do not want 
to introduce such a TTP and moreover, as stated above, the smartcard does not 
have an internal clock — time periods would introduce additional challenges. 

Req. IV: Profile building (under a pseudonym) must not be possible for any 
party involved in the protocol: As required in Sect. |4.l] the following points need 
to be met to prevent profile building under a pseudonym: 

1. Anonymous content (license) buying towards content provider, and anony- 
mous content execution towards content distributor. 

2. Unlinkability of content (license) purchases towards the content provider. 



11 Note that the CAD is in the user's domain and the user is seen as an attacker who 
tries to circumvent the license checking. 
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Fig. 4: Prevention of re-encryption key leakage in our protocol. 



3. Unlinkability of content executions towards the content distributor. 



(1) As we have pointed out in Sect. 5.1 users anonymously pay for con- 
tent (licenses), i.e., they do not need to register with the CP/CD and need not 
provide their payment details, which is why they stay anonymous during their 
transactions with CP and CD. 

(2) All the smartcards use the same certificate for anonymous authentica- 
tion towards the CP (Sect. |5.1| ), thus the CP cannot link different purchases 
made with the same smartcard. The smartcard's public key pk-tmp sc is newly 

-preventing the CP 



5.1) 



generated for each content (license) purchase (Sect, 
from linking purchases to each other. Moreover, the used anonymous payment 
scheme |3J provides unlinkability of individual payments. Furthermore, we as- 
sumed the connection between user and CP to be anonymized via Tor. Thus, 
unlinkability of content (license) purchases is achieved. 

(3) The user only provides the re-encrypted content key to the CD. Content i 
is only encrypted once during the initialization phase with cfcj and thus, cfc^ does 
not contain any information connected to the user or the user's CAD. As a new 
re-encryption key is generated for each content execution, the encrypted content 
key "looks" different for the CD each time and hence, the CD cannot link any 
pair (cki) pk -j cd , (cki) pk - kcd , for j ^ k to each other (see Fig. III. Further, we 



assumed the connection between the user and the CD to be anonymized via Tor. 
Therefore, multiple transactions executed by the user are unlinkable for the CD. 

Moreover, even if an attacker gets access to the user's mobile phone, he/she 
does not learn which content has been bought and executed. The list of available 
content is only revealed by the smartcard after authentication with the proper 
PIN and the mobile phone application does not keep track of executed content. 

Thus, to sum it up, profile building (even under a pseudonym) is neither 
possible for the CP nor the CD. 

6.3 Comparison to related work 

In Tab. [T] we compare our proposed scheme to related work in the field of privacy- 
preserving digital rights management. 



Table 1: Comparison of our scheme to related work in terms of properties. 



Properties 


Paper 
at hand 




10 




[91 


16] 





Need for TTP 


no 


yes 


yes 


yes 


no 


Need for trusted 
hardware 


yes 


no 


no 


no 


yes 


Flexibility in 
choosing a 
license model 


yes 


yes 


yes 


no 


yes 


Unlinkability of 
content executions 


yes 


yes 


yes 


yes 


no 


Computational 
efficiency 


good 


medium 


bad 


good 


good 


Flexibility in 
choosing content 
distributor 


yes 


yes 


yes 


yes 


yes 



Need for TTP One of the main advantages of our scheme compared to related 
work is that it does not need a trusted third party which is involved in the license 
checking process as in [9 10 during each content execution. In [6], the license 



server constitutes the TTP. However, it is not involved in the protocol for each 
single content execution but only once, when retrieving the license. 

Need for trusted hardware In our protocol a smartcard performs the license 
checking. Trusted hardware is not needed by other protocols that rely on some 



TTP. A trusted platform module (TPM) is needed in the protocol presented 
in Ff\ to securely store tokens at the user's computing platform. 

Flexibility in choosing a license model The protocols presented here and 
in [9lU0] allow for a license model to be chosen freely, e.g., content execution at 
most n times, up to a certain point of time, etc. The protocol presented in [6] 
does not allow such flexibility — once a license is bought for some content, it may 
be executed by the user as often as desired. The authors of u\ do not clearly state 
whether differentiated license models are intended. From the protocol's point of 
view, it should be possible to implement, e.g., execute at most n times-models 
as a token set provided by the content owner. Such token sets could include 
n tokens. Further, licenses that allow only a single content execution could be 
mapped to each token by the content provideirn later on. 

Unlinkability of content executions All of the approaches covered here, 
except for [7J, provide unlinkability of content executions and thus, prevent any 
party from building a content usage profile (under a pseudonym) . 

Computational efficiency In terms of computational overhead, our proposed 



scheme is very efficient, as shown in Sect. 6.1 The scheme presented in 10 
makes use of a number of different cryptographic primitives and thus performs 
less well. In [9], the entire content is re-encrypted for each content execution. 
Efficient standard cryptographic primitives are used in [6]p7|. 



Flexibility in choosing content distributor All the schemes presented in 
this overview provide users with the possibility to freely choose the CDs. In other 
two-party DRM scenarios, such a flexibility is typically not provided. 

7 Conclusion 

We have come up with a privacy-preserving multiparty DRM concept. Users 
can anonymously buy content licenses from a content provider and anonymously 
execute the content at any content distributor by, for example, streaming the 
content from content distributors nearby. Anonymity in this context means that 
none of the involved parties is able to build a content usage profile — not even 
under a pseudonym. In contrast to related work on privacy-preserving DRM, the 
approach presented in this paper does not employ a trusted third party. Smart- 
cards are used to check content licenses and grant execution if the license still 
allows the respective content to be executed — thus, enabling very differentiated 
license models. We implemented our concept on a state-of-the-art smartphone 
and proved its practicability for a multiparty DRM scenario in a mobile envi- 
ronment in which a user buys a license allowing the playback of, e.g., some TV 



Content distributor in our scenario. 



show — roaming in different regions, the user is free to choose the nearest stream- 
ing server (content distributor) and hence, getting the best throughput. As li- 
censes are bound to the user's smartcard, content usage is device-independent 
and the user may use any of his/her devices to playback the content. 
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